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Intro 

Welcome to Building Next Generation User Experiences @ NASA. We're both 
really excited to be here and with that being said. Let’s get started! 

Who are these guys? 

So we may look familiar to you... We were both here last year to present at 
SXSW on the UX of a Space Station. And we really enjoyed talking about it and 
people seemed to love it, so we decided to come back again to talk about some 
other things that we've made. 

So who are these guys? 

A little bit about ourselves. 

We’re two small town guys, designing at NASA. I should say we were, Sam 
recently is now a fellow at code for america. I'm still a designer and researcher at 
NASA. 

But we both have worked closely over the past few years making software for 
missions in our group. 

Team Photo 

And this is our team 

This awesome shot was taken at the launch for MSL, also known as the Curiosity 
rover. 

We're part of the HCI group at NASA. 

You'll also notice there are a lot of JPL shirts in the group. 

We also work very closely with the OPS lab at JPL on some of these products. 

But being called the HCI group does not really give you an idea of what we 
actually make or do other than that it probably invovles HCI. So let me go through 
show you. 

MCC APEX, PLATO, Score 

This is a shot of the Mission Control Center in Houston. We've made software for 
3 flight controller positions on the station. 

Starting from the left, APEX, which is a tool helps the ADCO flight controller 
orient and control the Space Station. It also helps handover control between the 
United States and Russia. 

Then in the middle have PLATO. PLATO helps flight controllers plan and orient 


the solar panels on board the Space Station. 

And then Score, Score is used by the OPS Planners to plan and schedule all of 
the crew activities on board the Space Station. And in addition to that it is also 
used to plan out any experiments on the station as well as other events such as 
space craft dockings. 

So you can see we have a lot of experience on making software for mission 
control on the space station. 

Playbook 

In addition to that we've also made software for the astronauts to use. 

This tool is called Playbook and it's made for the astronauts to view the plan that 
mission control has made for them. 

And it lets them view those activities, and indicate that the status of an activity, 
and also view procedures and comments on the plan. 

This software we hope to have on board the space station fairily soon. 

So we've made a lot of cool stuff in the past. 

OSTPV 

But one of the things that has come up time and time again, is that NASA 
software tends to look like this. 

And as designers that makes us a little sad. 

Everything is functional, but not exactly beautiful. 


Dreams of Sci-Fi Ills 

We dream of crisp Ills that invoke ideas of science fiction! 

We want the star trek LCARS interface, maybe even HAL! 

2001 Face Slide 

Okay maybe not HAL, we all know how that story ends.... 

Realities of Sci-Fi vs Real Space Missions 

But we want and are driving towards minimalist and simplistic Uls that gracefully 
execute users needs. 

Now, there are reasons why things don’t look that way 
Space is much more complicated than the way it is depicted in the movies 
Uls seen in SciFi don’t actually need to do much of anything, they just need to 
look good 

Uls at NASA have to do their job, and work all the time. 

But even with those differences aside, we’ve been working on changing this 


And broaden the idea what is a traditional NASA interface 

To try to make things look like and work like the way they do in Science Fiction 

Stories for Today 

So today we’re going to take you through 4 missions and 4 pieces of software 
that we’ve worked on over the years at NASA that have broken the mold in terms 
of what is traditional NASA software 
Some of these were prototypes, others full software projects. 

But each one of these had the same purpose of trying to push the boundaries on 
what is a traditional NASA user experience. 

4 Missions, From the Moon to Outer Space 
Today our journey will go from the Moon 
To Mars 
To Deep Space 

And outer space, and other worlds 

Story #1 LADEE and the Moon 

So we begin first with LADEE and the Moon. 

LADEE Slide 

LADEE, the Lunar Atmospheric Dust Environment Explorer 

A fantastic orbiter that recently launched 

Main science objective of analyzing the lunar exosphere 

Moon Surface 

And the lunar exosphere is the very thin atmosphere of the Moon. 

Now the lunar exosphere is not very dense at all, but when the Apollo astronauts 
were orbiting the moon, they noticed a glow coming from what appeared to be 
the lunar atmosphere. 

Apollo Pad 

And this is interesting because, there shouldn't be a glow there. 

Here's a sketch of what they saw. 

So this is just one of the many mysteries of the moon that LADEE is trying 
to investigate. In addition to many others. 

3 Science Instruments, 1 Engineering Instrument 

So how does it do this? 

It has 3 science instruments on board to do this. UVS, LDEX, and NMS. 

And one engineering instrument to test out high speed laser communication 
back to earth called LLCD. 

All very cool. 


LASS and LADEE (Background) 

So that's some background on the LADEE mission, but how were we involved? 
So how we were involved with the LADEE mission? 

We made mission planning software for the mission, called LASS, the Lunar 
Activity Scheduling System. 

To understand what is does and how it works is a bit complicated so let me 
explain 

Scientists and Engineers on the mission need to plan out what LADEE will do 
every day 

So if I’m a scientist and I want to do an activity I put it in our tool 

And more scientists, engineers put in what they want LADEE to do for the day 

And eventually we have a PLAN! 

But often what scientists want to do conflicts with what can be done, given the 
constraints of the orbiter. 

And our tool helps them out by identifying these conflicts, letting them know 
how these can be fixed 

And after all those conflicts are fixed we eventually get to a pristine plan 
(meaning there are no conflicts), filled with science and ready to go to the orbiter. 

This plan eventually goes to other tools where the plan is eventually turned 
into code that runs on the orbiter 

Working on the code directly would be too tedious, time consuming, hard to 
follow. 

So instead the mission uses our tool instead to work on this at a higher level. 
So it serves a very important part of the LADEE mission. 

And then science happens! And everyone loves science. 

LASS, very important for the mission 
Anyway that was the major tool that we made for the mission. 

It’s pretty important to maximize the efficiency of the orbiter 
Without it means less science, and less mission productivity 
So this really needs to work reliably and be very stable. 

Our first priority was making sure this was rock solid 
Served all the needs for the mission 
And it did this very well. 

Interesting things that occurred during the mission 

But the way your software will get used will always surprise you. 

The interesting thing is that many people were using this software as a map of 
what LADEE will do tomorrow as well as what LADEE is doing now. 

And honestly, we never really designed this tool to do that, it was specially made 
for crafting these plans. But as our tool was deployed we started to see our tool 
getting branched out into other uses. 


So we wanted to see, what would it look like if we could design for these needs? 


Demo of LASS Board (with fake data) 

And that brings us to our first demo. And that brings us to LASS Board. 

We wanted to make a beautiful persistent display that took the data in our tool, 
And really showed the relationship of what they planned the orbiter to do and 
where it was on the moon. 


And that’s very different from the way we were traditionally displaying it in our 
software on a mission. 

We had all of this data in LASS, but it was not displayed in a spatial context, it 
was just sine waves and blocks 

That makes it hard to understand and it also didn’t convey the feeling that this is 
a space mission, that this is running on a spacecraft that is orbiting the moon! 

So LASS Board plays back these plans and shows a visual representation of 
what LADEE will do on a given basis. 

LASS Board Ul Features 

So let's walk through this interface. 

The red dot is LADEE, and the line is it's orbital path. The bands are activities 
that are coming up that will run on the LADEE orbiter. These are a mix of science 
and engineering activities; basically whatever LADEE was planned to do at that 
time. 

On the right hand side we have both the playback time of this plan, and the 
latitude and longitude of the predicted position for LADEE. 

Then below that we have the activities that are planned to be run by LADEE that 
are coming up or currently executing. 

Then if I click on the moon, I get a top down surface projection of where LADEE 
will be with it's orbital path and upcoming activities. 

So it's a very nice and sleek minimalist view of what LADEE is going to do for the 
day. 


Minimalist Visualizations for Mission Control 


And this minimalist visualization style, this is the style and aesthetic that we're 
driving toward for our new interfaces for missions. LASS was VI , and LASS 
Board, this is V2. 

Story #2 Curiosity Rover and Mars (Background) 

And now we go from the Moon to Mars 

Curiosity Rover, I think most people are familiar with this one... 

SUV Sized rover on Mars 

More instruments, more people, more complexity. 

MSLICE and Curiosity 

Like LASS for LADEE things need to be planned out to efficiently use the rover 
More instruments means many different teams of people 
They all need to work together 
To use the same physical resource, the mars rover. 

So our tool MSLICE that we worked on with our friends at JPL helps them out 
by making a plan, and checking for flight rule, resource, power, and data 
violations. This is very similar to the tool for the LADEE orbiter called LASS that 
you saw before. 

Much more than just making a plan, an ecosystem for science operations. 

It also does much more than that. 

Downlink Image 

It shows downlink images from Mars to scientists and engineers. 

Targets 

It allows users to pick targets of where science should occur. 

Sequences 

It also helps users write the code that gets uplinked to the rover. And this is 
obviously not real code, but they all sort of look like this. 


Needless to say, this took a lot of effort to build 

Needless to say, this took a lot of effort to build 
Everything just needs to work and work reliably. 

And took a lot of effort to get there. But we did. And things worked well. 

Where do we improve on things? 

And after things settled down we could take a retrospective look at how we 
could make things better 

We noticed that there were a lot more people using our software than we 
expected on the mission. 


Users that were never explicitly told to use our tool started picking it up. To look 
at images, to look at plans, to look at targets, to look at sequences. 

These new users were using it to converse with others and be part of Science 
discussions and science process. 

Experts vs. Casual Users. 

This was an interesting situation because it was a very different user 
community from the past. Our tools were designed for specific types of expert 
users on these missions. And because of that it was never designed to be walk- 
up and use. 

But now that we had this new larger user community, we wanted to make their 
lives easier, and at the same time make things more efficient for expert users as 
well. 

Areas to improve on, Search View 

We also had areas of the existing tool that we wanted to improve on. 
Specifically, the search view in our MSLICE tool was particularly hard to use and 
it never got much love. It was also interesting in that it is the only way for users to 
open up content in our tool. 

And what that meant was that most users weren't actually using the Search view 
for searching, they were just using it to open up files. So search was sort of a 
misnomer for this part of the interface, it was really the main view to open and 
access content. 

The Science Process: Intent and Discussion 

And in addition to that there were parts of the science process that our tool was 
not capturing. 

The science process is full of discussions 

Back and forth discussions about what they want to put in the mission plan for 
curiosity to do. 

And there’s a lot of excellent knowledge going back and forth 
And right now it’s not being captured. 

Discussion->lntent->lmages->Targets->Plans->Sequences-> they’re all 
connected 

Another thing was that all of the data products used in our tool were connected to 
each other as part of the science planning process. 

So when scientists are planning they are discussing what they're going to do for 
the day and all of these products are connected. 

And all of these products are connected 

And rationale was made on why things were done in meetings, but there was 
no good way of capturing that in our tool. 

And these connections, the relationships from images to targets to plans to 


sequences were not being captured. 

And these we thought were one of the most important things to capture because 
it tells the story of why things were done, the narrative behind the activities that 
were chosen for the day. 

Snapshot: Making a Pinboard for Scientists 

So how could we make our software more usable for casual users, provide a 
better way to browse content, and show the narrative of how these products 
relate to one another? 

Well our idea was to make Pinterest for scientists. No really. 

We call it Snapshot, b/c it gives you a little snapshot of what’s going on in a 
mission 

Now this is a work is progress, but we wanted to show you what we're aiming for. 

All of the data products in our tool are displayed as cards. Which gives you a nice 
view of what is inside the data product. You can browse information without 
having to open it up. 

Users can add cards to an existing collection, such as Rocknest, or they can 
create their own. 

Collections concept, relating data to areas of interest 

And users can collaboratively create these collections in meetings 
And look back at them for research later on. 

Users can also send these collections to each other as links. 

Clicking in on content 

To view data products, users can view their content with just one click. There's 
very little friction to access content 

The idea is that in the future, parts of science planning can occur here in 
Snapshot, rather than need to be done in our existing expert tools. 

So in the future light weight planning or making science targets, which is what 
you're looking at here, could be done inside here, rather than in our existing 
expert tools. 

But if needed, experts users can also easily open up this content in our expert 
planning tool, as well as download the content to be used for other specialized 
tools. So it's very simple but also very versatile. 


Closer 


And the lesson here, the key takeaway is we're now working on software that is 
inviting for all users. We believe it's important for everyone on a mission involved, 
especially as missions get larger and involve many more people than before, 
such as on MSL. 

And we think that the Snapshot concept is key to making that happen. 

Now i'm going to hand it off to Sam. 

Story #3: DSN and Deep Space 

Deep Space Network is a set of three antenna sites around the world. 

In Barstow, CA. Madrid, Spain. Canberra, Australia. 

Allows them to get global coverage. 

Used as the communication channel for many space missions, including MSL. 
Each communication is rented out, and called a ‘link’. 

The people that work there are called, appropriately, link operators. 

Link operators have a setup that looks like THIS (photo) 

Lots of monitors, let’s them see lots of connection details simultaneously. 

The actual software they were using looked like this (photo) 

Despite the look, it’s actually quite very useful. Not cool, but useful. 

Then, the “software experts” stepped in. 

I’m not going to name name here, but they treated the project like building a 
shuttle. 

NASA builds software like they build space shuttles. 

I mean this in a lot of ways. 

Building a shuttle 101 . 

Checklists. Lots of checklists. 

A bunch of group make different ones. Others enforce it. (Need more detail 
here) 

And they applied the same principles to software. 

Didn’t talk to users. Not part of the checklist. 

Went through the software and applied the NASA Ul checklist, 
compounding the problem: checklists were designed LONG ago, often for 
physical Uls 

(do we have access to the design checklist for space station?) 

“This goes against the established design approach and principles.” 

“ I understand that it may go against the design approach however it is one of 
the largest criticisms of the IRIS displays.” 


UX design is about users, not about checklists, 
this is the point where we got involved, 
can say with some relief, our team doesn’t have checklists, 
more to the point, we don’t have a management chain that believes in 
checklists. 

that’s pretty rare at nasa 

went out there and TALKED to them. TALKED! 

a couple things we learned 
love text interface 
but things were too spread out 

often a disconnect between terminal interface and everything else 
wanted to be able to manage two links at the same time 
wanted to quickly see ALL the information 
so we created a quick prototype of what this could look like 
and now i’d like to share it with you 

DEMO of deep space network Ul 
simple, all info on one page, no hidden information, just scroll 
scroll ability = fun factor, turns out link operators enjoy fun too. 
text allows quick input, but also shows where the edit is being applied 
more complex terminal commands can be integrated too! 

what’s interesting is that i’ve never seen something like this before 
what checklist would you apply to this 
use design guidelines, not checklists, 
measure your success against the happiness of your users 
saying it is. but to actually do this, need support from above! 
suggestion: nasa needs a chief design officer, 
someone’s whose role is to enable a design culture, that’s missing, 
someone who can empower people to build software differently than a shuttle 

Story #4: Kepler and Other Worlds 

Kepler 

Looking for other planets in our galaxy 

Deceptively simple: looks at the brightness of stars for years on end 
If that brightness dips, regularly, it’s because a planet is passing in front of the 
star 

Lots of math goes into this as well, but that’s the basic idea 

It’s been called “the most romantic NASA mission” and i agree, 
and it’s been wildly successfully, found hundreds of confirmed planets. 


evidence for many more! 

but for a long time it didn’t get much attention 

and i think it’s because they started by doing something most NASA missions 
do 

they focus internally, think about science only 
when you do this, your tools reflect it 
csv, scripts, other very practical things 
they certainly don’t appeal to an outside audience, and they don’t tell your 
story 

and if you think about it, they key to star trek level software is that it helps you 
tell a story 

Lesson #4: Too often, NASA doesn’t think about the public as part of their 
audience 

And in this situation, I want to present Kepler as a kind of success story 
They included people from public outreach 

and these people do a fantastic job of asking what do we tell the general 
public? 

in the case of kepler, they pulled us in and asked us to help visualize things 
and i’d like to share that work with you today 

we started with this open source work from Jer Thorpe 
beautiful, but hard to understand 
colors don’t map to how we intuitively understand things 

DEMO of kepler visualization 
first you can see is lots more planets, we update the data 
colors map to how’d we guess hot and cold to be. 
probably not a super accurate scale, but it’s about story telling 
added control, and filters, so you can’t start to actually interact with the data 
filter, and see all the newly confirmed planets, change over time, 
but as we played around with it, still didn’t feel right, what were we actually 
seeing here? entire solar systems! 

so we made that view! and i love it. i understand what i’m seeing finally 
another story i wanted to tell is, what is kepler actual seeing? 
so we made this view: sensors lined up with the stars themselves 
can really help give a sense of just how common these planets are 
there’s lot more, come up afterwards and play with it 

Compare this visualization to a csv file, or a scientific paper 
This is the difference when you think about the public as part of your audience! 
but, the story doesn’t end here... 


as almost a perfect illustration of the how nasa prioritizes things: 
finished this, but they didn’t want to share it until paper was published 
and if you know anything, papers get delayed 
2 months later, the nytimes published this: 

http://www.nytimes.com/interactive/science/space/keplers-tally-of-planets.html 
before we published ours! 
we got scooped by the nytimes! 

gives you a sense of the different priorities 

suggestion: include more public outreach folks, empower them 
nasa does amazing work, and should be able to tell it’s story. 

SECTION: Conclusion & Recommendations 

Those were the 4 stories we had. We hope you enjoyed them. 

If there’s one key idea: NASA does amazing work, and the design of it’s 
software should reflect that 

And we believe it can! 

We believe it can be visual. 

We believe it can be social. 

We believe it can introduce Ul concepts that didn’t exist before. 

We believe it can inspire people. 

And finally, we hope you enjoyed the demos. 

We’ll have them all up here after for you to play with, so come up and say hello. 
And with that, we’ll take questions. 

ROARING APPLAUSE 


